Moving an interval can overflow in case the new values of the interval can't be represented by the type.

In the majority of use cases this can probably be ignored, but in those cases where an overflow does occur, an assumption was made that the most likely desirable behavior is to move the interval as far as possible. I.e., 'clamp' the operation to the possible value range.

But, to ensure the caller can still tell overflowed operations apart from fully successful shift operations, the actual amount by which the interval is shifted is included in the return value.

In addition: while writing unit tests for shift, I noticed some errors on EmptyIntervalUnion operations, which are now fixed.

Some things left to consider:

• Add a test to verify the assumption that "all negative values of TSize have a positive counterpart". And, is this a fair limitation for potential types of TSize? Found a workaround/no longer a requirement.
• Deal with precision issues at large values. This can probably lead to intervals "collapsing" to single values, and failing on initialization with two exclusive bounds. If dealt with, maybe increase possible range of float and double again to allow loss of precision. **Postponed: Likely error when shifting intervals of types which have loss of precision #64 **
• Improve shift overflow tests so they are less sensitive to precision issues. Maybe add extra test input if relevant?
• Add test + fix to prevent unsafeShift infinite loops on "infinity" values.
• Should the actual resulting shifted value in case of overflows be signed? Is it currently consistent? Should be signed now, but maybe needs more tests.
• Shift union pairs (TODO item)